Why Do We Need 100 Customers?

A software development co-worker of mine was working on a project as an analyst. One day, the manager she was working for came into her office and asked "Why have you requested 100 unique customers be created in the test database instance?"

As a systems analyst, she was responsible for helping the business analysts define the requirements and the acceptance tests for a large, complex project. She wanted to automate the tests but had to overcome several hurdles. One of the biggest hurdles was the fact that the system under test (SUT) got much of its data from an upstream system and it was too complex to try to generate this data manually.

She came up with a way to generate XML from tests captured in spreadsheets. For the fixture setup part of the tests, she transformed the XML into QaRun (a Record and Playback Test (see Recorded Test on page X) tool) scripts that would load the data into the upstream system via the user interface. Because it took a while to run these scripts and for the data to make its way downstream to the SUT, she had to run these scripts ahead of time. This meant that a Fresh Fixture (page X) strategy was unachievable; a Prebuilt Fixture (page X) was the best she could do. To try and avoid the Interacting Tests (see Erratic Test on page X) that were sure to result from a Shared Fixture (page X), she decided to implement a virtual Database Sandbox (page X) using a Database Partitioning Scheme based on a unique customer number for each test. This way, side effects of one test couldn't impact any other tests.

Given that she had about 100 tests to automate, she needed about 100 test customers defined in the database. And that's what she told her manager.

Page generated at Wed Feb 09 16:39:04 +1100 2011